Fixing the PNETLab Wireshark "Access Denied" Error: A Step-by-Step Guide

Network Automation & Labs Series by IAMTAC Team

Live packet analysis is one of the most critical phases of network engineering validation. However, when spinning up topologies in PNETLab or EVE-NG, a common integration breakdown frequently halts progress.

You right-click a node interface, click Capture, and instead of seeing traffic streams, a command prompt pops up and rejects the connection:

Connecting to root@192.168.1.45... 
Access denied

This error does not mean your Wireshark application or your network node is broken. It indicates an authentication or SSH host-key mismatch between your local machine's background capture client (the integration pack wrapper) and your remote server instance.

Here is the exact playbook to fix it and get your live traffic streams back online across Windows, macOS, and Linux.

Understanding the Root Cause

When you trigger a packet capture from the PNETLab web portal, your browser executes a local integration wrapper script. This wrapper utilizes a lightweight background SSH utility to log into your virtual machine as root, extract the interface traffic, and pipe it directly into your local Wireshark application.

The connection fails with "Access Denied" due to two primary bottlenecks:

  1. Password Mismatch: You changed the default root password on your main server console, but your local desktop wrapper script is still attempting to pass the default credential (pnetlab or eve).
  2. Uncached SSH Host Key: The background execution engine encounters an invisible security confirmation prompt from Windows or Unix because your operating system hasn't explicitly trusted the cryptographic fingerprint of the server.

Solution 1: Update Your Local Wrapper Configuration (Windows)

If you changed your root password from the default to a secure custom password, you must manually align your local client pack scripts to match the change.

  1. Open File Explorer on your local Windows machine.
  2. Navigate to your integration pack installation directory:
    • Path: C:\Program Files\EV-NG\ or C:\Program Files\PNETLab\
  3. Locate the file named wireshark_wrapper.bat (or simply wireshark_wrapper).
  4. Right-click the file and select Open with > Notepad.
  5. Look for the configuration line defining the password variable. It typically looks like this: 
    SET PASSWORD=pnet
  6. Modify the value after the = sign to match your custom root password exactly.
  7. Save the file (Ctrl + S) and exit the editor.

Solution 2: Cache the Server's SSH Key with PuTTY (Windows)

If your password is correct but the script terminates instantly, the background utility (plink.exe) is likely waiting for an invisible security prompt confirmation. You must manually accept and cache the server's fingerprint.

  1. Launch PuTTY on your Windows desktop.
  2. In the Host Name (or IP address) field, type the IP address of your server (e.g., 192.168.1.45).
  3. Ensure the connection type is set to SSH (Port 22) and click Open.
  4. A PuTTY Security Alert popup window will appear warning you about an un-cached host key.
  5. Click Accept (or Yes) to permanently trust the server fingerprint.
  6. Log in once as root to verify everything connects successfully, then close the PuTTY window.

IAMTAC Pro-Tip: Always open a quick manual PuTTY or SSH session to any newly deployed server or virtual environment to accept host keys early. This prevents background automation scripts from silently failing down the road.

Solution 3: Configuration for macOS & Linux Users

If you are running PNETLab/EVE-NG integration packs on an Apple or Linux client machine, your wrapper script relies on native SSH instead of plink.exe.

Step 1: Pre-cache the Host Key

Open your local terminal app and manually SSH to the server once to accept the cryptographic ECDSA/RSA fingerprint:

ssh root@192.168.1.45

When prompted: Are you sure you want to continue connecting (yes/no/[fingerprint])?, type yes and press Enter.

Step 2: Edit the Unix Wrapper Script

If your password is custom, update your local integration configuration:

Open the file in terminal using your favorite text editor (e.g., nano):

sudo nano /usr/local/bin/wireshark-wrapper.sh

Locate the password variable string, update it to your custom credential, save (Ctrl+O), and exit (Ctrl+X).

Solution 4: The Zero-Configuration Alternative (Docker Wireshark)

If you are working on a managed corporate laptop where you lack administrative permissions to edit program files, install wrappers, or modify system binaries, you can completely bypass local operating system restrictions by using the built-in web container feature.

  1. Navigate to the top global menu bar of your server's web dashboard.
  2. Toggle your console setting from Native Console to HTML Console.
  3. Right-click your target lab node, hover over Capture, and select the desired network interface.
  4. Instead of attempting to launch a local application, a Dockerized Wireshark instance will spin up inside a new browser tab.

While HTML console mode saves you from configuration headaches, using the Native Console (Solutions 1, 2 & 3) remains highly recommended for long-term lab environments. Native applications offer smoother performance and direct access to your local Wireshark settings, custom profiles, and custom coloring rules.

Troubleshooting Checklist for Lab Environments

Did this fix your capture issue? Let us know in the comments below if you are still experiencing integration script blocks, and don’t forget to subscribe to help@iamtac.com for more deep-dive networking and virtualization guides!